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1  Getting  Started 

1.1  What  is  WireLisp? 

VVireLisp  is  a  hierarchical  circuit  structure  description  language  that  combines  the  intuition  of  schematics 
and  the  generality  of  procedural  description.  It  is  different  from  other  similar  tools  in  that  the  schematics 
and  procedural  descriptions  are  closely  intertwined.  More  specifically,  WireLisp  is  embedded  in  Lisp  but 
provides  graphical  constructs  for  the  most  common  procedural  constructs.  A  WireLisp  program  consists  of 
a  set  of  device  definitions,  each  described  in  the  most  convenient  way:  Lisp  expressions  may  be  embedded  in 
schematics  and  schematics  may  be  embedded  in  Lisp  as  well.  This  allows  descriptions  to  be  highly  expressive, 
yet  easily  specified  and  understood. 

This  manual  defines  the  WireLisp  language.  Wirelisp  is  implemented  in  Lisp  and  arbitrary  Lisp  can 
be  used  in  Wirelisp  programs.  A  separate  manual,  Drawing  WireLiap,  describes  how  to  draw  WireLisp 
constructs. 

1.2  Running  WireLisp 

The  current  implementation  of  WireLisp  uses  the  Xdp  drawing  program  as  the  graphics  front  end  and  T  as 
the  base  Lisp  language.  Xdp  is  an  interactive  drawing  editor  developed  at  Carnegie-Mellon  University,  T  is 
a  dialect  of  Scheme  developed  at  Yale  University. 

1.2.1  Setting  Up 

On  VLSI  machines,  you  should: 

•  make  sure  you  are  using  XII  Version  3  window  system; 

•  make  sure  /usr/bin/Xll,  /u2/t/bin  and  $UW_VLSLTOOLS/bin  are  on  your  search  path; 

•  set  up  the  environment  variable  DPPATH  which  contains  the  search  paths  for  your  Xdp  files  (with 
.dp  extension); 

•  set  the  environment  variable  WLPATH  which  contains  the  search  paths  for  your  WireLisp  files  (with 
•  wl  extension);  1 

•  set  up  the  T  initialization  file  init.t  at  your  home  directory.  This  file  is  automatically  loaded  upon 
entering  T. 

1.2.2  A  Sample  Session 

In  this  section,  we  will  go  through  a  simple  example  to  show  how  WireLisp  programs  are  executed. 

Suppose  we  want  to  create  the  .sim  file  for  a  device  named  clkinv  and  we  use  the  default  CMOS  library 
which  includes  the  primitives  ptrans  and  etrans.  There  are  four  basic  steps: 

1.  Use  Xdp  to  prepare  the  drawing  for  clkinv  (see  Figure  1)  and  save  it  in  the  file  clkinv. dp; 

2.  Enter  T  (version  3.1).  Note  that  the  default  initialization  file  is  automatically  loaded  which  in  turn 
requests  the  loading  of  the  Wirelisp  initialization  file. 

3.  Load  the  WireLisp  interpreter  by  typing  (wirslisp).  By  default,  the  device  library  is  CMOSLIB  and 
the  output  file  extension  is  .sim. 

4.  Make  the  root  device,  which  in  this  case  is  clkinv  by  typing  (aaks  clkinv). 

1  This  it  not  implemented  yet. 
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stehekinX  t3.1 

T  3.1  (5)  MC68000/UIIX  Copyright  (C)  1988  Yal*  University 
; Loading  /ul/zhanbing/init . t  into  USER-EIV 

;  Loading  /usr/lis/src/vlai/vlsi-3.2/lib/*ir*lisp/uiralisp.no  into  USER-EIV 
T  Top  level 
)  (virelisp) 

; Loading  /usr/lis/arc/vlai/vlsi-3.2/lib/vireliap/device.ao  into  USER-EIV 
; Loading  /uar/lia/arc/vlai/vlai-3.2/lib/aireliap/inatanca.ao  into  USER-EIV 
; Loading  /oar/lia/arc/vlai/vlai-3.2/lib/aireliap/aignal.ao  into  USER-EIV 

; Loading  /nar/lia/arc/vlai/vlai-3.2/lib/aireliap/c»oalib.ao  into  USER-EIV 
)  (aake  clkinv) 

Running  dp2«l  on  clkinv. dp  ... 
pra-procaaa  clkinv. *1  . . . 

; Loading  clkinv. vlpp  into  USER-EIV 
;no  value 
)  (exit) 

stehekinX  aore  clkinv. vl 
(-device-  (clkinv  out  in  dk  elk-) 

(acceaa  in  out  elk  elk-) 

(local  tp  te) 

(-1-  ptrana  in  Vdd  tp) 

(-1-  ptrana  elk-  tp  out) 

(-1-  etrana  elk  out  te) 

(-1-  etrana  in  te  GID)) 
stehekinX  aore  clkinv. sia 
I  units:  100.0  tech:  caos-s  ioraat:  UCB 
p  CLK-  VDD  TP  2  2 
p  II  TP  OUT  2  2 
e  II  OUT  TE  2  2 
e  CLK  TE  GID  2  2 
stehekinX 

clkinv. wl  is  derived  from  clkinv.dp  by  running  the  schematics  extractor  dp2wl,  and  clkinv.wlpp,  which 
is  deleted  after  loading,  is  derived  from  clkinv.wi  by  running  a  preprocessor.  The  output  file  is  named  after 
the  root  device,  which  in  this  case  is  clkinv.sim. 

Note  that  in  the  above  sample  session,  we  used  the  standard  T  heap  size,  i.e.  4096000  bytes.  However, 
the  user  may  need  to  use  a  smaller  heap  size  due  to  inadequate  memory.  The  heap  size  is  specified  with  the 
-h  flag.  For  example, 

%  t3.1  -h  1024000 

claims  a  heap  of  1024000  bytes.  If  the  given  size  is  smaller  than  the  minimum  required  heap  size  (524280 
bytes),  T  will  use  the  minimum  size  instead. 


2  Introduction 

In  this  section,  we  will  go  through  the  design  of  clkinv  to  show  some  basic  concepts  of  WireLisp.  Since  this 
manual  focuses  on  the  procedural  aspect,  we  will  examine  the  .wl  files.  2 

In  WireLisp,  each  device  (or  module)  is  a  procedure.  A  device  is  instantiated  by  a  call  on  this  procedure. 
Because  a  device  procedure  may  have  parameters,  it  actually  defines  a  family  of  devices,  instances  of  which 

3  In  practice,  the  user  makes  the  drawings  and  the  system  automatically  creates  the  .wl  files  by  running  dp2wl. 
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are  produced  by  invoking  the  procedure  with  particular  parameter  assignments.  For  example,  let  us  look 
the  device  procedure  of  clkinv.3 

;;  ‘clkinv’  has  4  signal  paraastsrs:  out,  in,  elk,  elk-. 

(-device-  (clkinv  out  in  elk  elk-) 

;;  all  4  signal  paraastsrs  are  accessed  as  siapls  signals. 

;;  This  is  required  only  if  clkinv  is  the  root  device. 

(access  out  in  elk  elk-) 

;;  there  are  two  local  signals  which  are  visible  only  inside  ‘clkinv*. 

(local  tp  te) 

;;  'clkinv'  is  comprised  of  the  leaf  devices  —  P  and  E  transistors. 

;;  'ptrans*  is  instantiated  with  the  default  width  (2)  and  length  (2). 

(-1-  ptrans  in  Vdd  tp) 

; ;  Connections  that  share  the  ease  signal  are  physically  wired  together. 

;;  Ex.  dram  of  one  ptrans  is  wired  to  source  of  another  via  sharing  ‘tp* . 

(-1-  ptrans  elk-  tp  out) 

;;  'etrans'  is  instantiated  with  the  default  width  (2)  and  length  (2). 

(-1-  etrans  in  GID  te) 

(-1-  etrans  elk  te  out)) 

An  instance  of  clkinv  is  formed  by  instantiating  ptrans  and  etrans  in  turn  and  connecting  the  resulting 
four  instances  together.  Device  instances  are  connected  by  signal  names.  When  a  device  is  instantiated,  the 
signal  names  are  passed  as  parameters  to  the  device  procedure.  All  signals  must  be  declared  before  they  are 
used.  There  are  three  types  of  signals  in  a  device  definition: 

•  Global  signals  are  visible  to  all  device  instances.  WireLisp  provides  two  default  global  signals:  Vdd  and 
GID. 

•  Local  signals  are  visible  only  within  the  device  in  which  they  are  declared.  For  example)  clkinv  has 
two  local  signals:  tp  and  tw. 

•  Signal  parameters  are  passed  in  from  other  devices.  For  example,  clkinv  has  four  signal  parameters, 
out,  in,  elk  and  elk-. 

Signals  can  be  defined  to  have  structures,  that  is,  composed  hierarchically  of  other  signals.  These  signals 
are  called  cables.  Both  homogeneous  structures  (BUS)  and  heterogeneous  structures  (SI)  can  be  specified. 
The  use  of  structured  signals  increases  the  level  of  abstraction  and  decreases  the  size  of  the  program  by 
bundling  several  related  signals  into  one  cable.  For  example,  clkinv  can  be  defined  equivalently  as. 

;;  'clkinv'  has  3  signal  paraaeters :  ‘out’,  ‘in’,  'phi'. 

(-device-  (clkinv  out  in  phi) 

;;  'out'  and  ‘in’  are  siaple  signals,  but  ‘phi’  has  a  structure. 

(access  out  in  (phi  (SI  H  L))) 

(local  tp  te) 

(-1-  ptrans  in  Vdd  tp) 

(-1-  ptrans  phi.L  tp  out)  ;  ‘elk-’  is  replaced  by  ‘phi.L’. 

(-1-  etrans  in  GID  te) 

(-1-  etrans  phi.H  te  out))  ;  ‘elk’  is  replaced  by  ‘phi.H’. 

The  -I-  function  for  instantiating  a  device  can  be  intermixed  freely  with  other  Lisp  code.  For  example,  we 
can  expand  the  original  clkinv  to  N  bits: 

3  Comment*  ere  preceded  by  one  or  more  eemicolone  and  ended  by  the  end  of  the  line. 
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;  I  input/output  bits. 

;  &  common  clock  signal. 


(-dsvics-  (I-clkinv  out  in  phi  I) 

(access  (out  in  (BUS  1  I))) 

(accsss  (phi  (SI  H  L) ) ) 

(repeat  ill 

(-1-  clkinv  out[i]  in[i]  phi))) 

This  defines  a  3-level  device  hierarchy:  I-clkinv  -*  clkinv  — *  ptrans  and  strans.  When  a  hierarchi¬ 
cal  circuit  description  is  fully  elaborated,  all  that  remains  is  the  entire  set  of  interconnected  leaf  devices.  If 
each  instance  of  the  leaf  devices  simply  outputs  a  line  describing  itself,  then  these  outputs  are  concatenated 
to  form  the  output  of  the  program.  For  example,  the  leaf  devices  in  the  default  CMOS  library  are  ptrans 
and  strans.  If  we  want  to  create  the  net  list  for  I-clkinv  with  N  =  2,  we  execute: 

(■ake  I-clkinv  2) 

The  output,  saved  in  the  default  file  N-clkinv_2.sim,  *  would  be: 

I  units:  100. 0  tech:  caos-s  format:  UCB 
p  I*[l]  Vdd  C LSI IV- 1/TP  2  2 
p  PHI.L  CUCIIV-l/TP  OUT Cl]  2  2 
s  IlCl]  GID  CLKIIV-l/TE  2  2 
•  PH2.H  CUC1IV-1/TB  0UT[l]  2  2 
p  IIC2]  Vdd  CLKIIV-2/TP  2  2 
p  PHI.L  CLKIIV-2/TP  OUT [2]  2  2 
s  II [2]  GID  CLKIIV-2/TB  2  2 
e  PHI.H  CLKIIV-2/TH  OUT [2]  2  2 

Note  that  the  names  of  local  signals  in  clkinv,  tp  and  ts,  have  been  prepended  with  the  distinct  instantiation 
paths:  clkinv-1/  and  clkinv-2/.  This  is  necessary  in  order  to  distinguish  their  occurrences  in  different 
instances  of  clkinv. 

In  the  next  few  sections,  we  will  formally  define  the  syntax  and  semantics  of  WireLisp  constructs.  We 
start  with  devices  and  then  discuss  signals. 

3  Device  Definitions 

A  device  is  a  procedure  that  defines  a  family  of  circuits  with  similar  structure.  The  parameters  of  the  device 
determine  which  instance  of  this  family  is  to  be  built.  A  device  is  defined  by: 

(-device-  ( dev-name  signal\  signal j  ...  signal 

gen-parami  gen-paramj  ...  gen- para 

((opt-param-name i  default-valvei)  ...  ( opt-param-name »  defaiiH-valxiek))) 

access-declarations 

local-declarations 

temporary-variable-bindings 

device- description) 

where, 

1.  dev-name  is  the  name  of  the  defined  device.  The  keyword  -device-  is  parallel  to  the  keyword  define 
in  T. 

2.  signah  stgnalj  ...  stgnaim  are  formal  signal  parameters.  Their  actual  values  determine  how  the  in¬ 
stantiated  device  is  connected  with  other  parts  of  the  circuit.  Signal  parameters  are  mandatory  and 

4 The  parameter  value  3  is  appended  to  the  device  name  in  order  to  distinguish  between  different  instances  of  the  same 
family. 
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passed  by  position,  i.e.  the  first  actual  signal  is  passed  to  the  first  formal  signal. 

3.  gen-param\  gen-param?  ...  gen-paramn  are  formal  general  parameters.  They  can  be  of  any  type  except 
signals.  Typically  they  are  integers  that  specify  the  size  of  a  circuit,  such  as  I  in  the  device  I-clkinv. 
General  parameters  are  also  mandatory  and  passed  by  position. 

4.  lYopi-panjm-namei  default-valuei)  ...)  are  optional  parameters  which  are  passed  by  name,  just  like 
keyword  arguments  in  Common  Lisp5.  The  order  of  these  parameters  does  not  matter.  All  optional 
parameters  must  be  declared  in  the  device  definition.  If  a  device  is  instantiated  with  an  undefined 
optional  parameter,  WireLisp  simply  ignores  that  parameter. 

There  is  a  special  optional  parameter  called  inataacw-iuuM  (or  II  in  short)  used  to  specify  names 
of  device  instances-  It  can  be  thought  as  a  system-defined  optional  parameter,  i.e.  every  device 
automatically  defines  it  as  an  optional  parameter.  Device  instance  names  are  used  to  construct  the 
unique  device  instantiation  path  names  (see  Section  5.2).  Normally,  the  user  should  not  assign  the 
same  name  to  different  instances  within  a  device  definition.  When  a  device  is  instantiated  without  an 
instance  name,  the  system  will  automatically  generate  a  unique  instance  name. 

5.  access-declarations  is  a  sequence  of  access  declarations  which  specify  how  cable  parameters  are  ac¬ 
cessed  inside  this  device.  Note  that  this  declaration  is  only  necessary  for  those  parameters  whose 
components  are  to  be  accessed. 

6.  local- declarations  is  a  sequence  of  local,  slocal  and  shadow  declarations  which  create  signals  visible 
only  within  the  device.  For  cables,  this  declaration  creates  not  only  their  wire  structure  but  also  the 
access  structure. 

7.  temporary-variable-bindings  is  a  sequence  of  binding  expressions  like: 

(dsfvar  (van  valusi)  ...  (var*-  valusjf)) 

For  example, 

(dsfvar  (I  (aizw-of  in))  (II  (-  I  1))) 

dsfvar  resembles  very  much  like  1st*  in  T,  i.e.  the  bindings  evaluated  first  are  visible  to  later 
evaluations.  Note  that  no  dsfvar  binding  is  visible  to  any  signal  declaration. 

8.  device-description  is  a  sequence  of  intermixed  T  and  WireLisp  expressions  which  define  how  the  device 
is  constructed. 

4  Device  Instantiations 

In  the  object-oriented  view,  a  device  definition  characterizes  the  common  properties  of  a  class  of  objects, 
and  a  device  instantiation  creates  an  object  of  that  class.  When  a  device  procedure  is  called  with  actual 
parameters,  am  instance  of  that  device  structure  is  created.  All  instances  of  a  device  share  the  same  or 
similar  circuit  structure,  but  differ  in  what  actual  parameters  are  used  in  their  instantiations. 

4.1  Instantiating  a  Device 

A  device  can  be  instantiated  via: 

(-1-  dcv-name  signal  signal?  ■  signal 

gen-param\  gen-par-jm?  ...  gen-paramn 

(prop  (opt-param-namei  valuer)  ...  ( opt-param-namet  va/uey))) 
where,  the  number  and  the  order  of  mandatory  parameters,  i.e.  signals  and  general  parameters,  must  match 
the  corresponding  formal  parameters  in  the  definition.  The  order  of  optional  parameters  does  not  matter 
because  they  are  passed  by  name.  The  keyword  prop  indicates  that  the  following  is  a  list  of  optional 

ST  does  not  have  keyword  argument*. 
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N-clkinv  (N=2) 


clkinv-1 


clkinv-2 


clklnv-l/pcr«n*-2  clfcinv-l/«tran*-l  clkiu*-2/ptr*n»-l  elltlnv-2/«tr»n»-l 


Figure  2:  the  instantiation  hierarchy  in  (make  I-clkinv  2) 


parameter  pairs:  (name  value).  If  there  is  no  actual  value  specified  for  an  optional  parameter,  WireLisp  fills 
in  its  default  value  as  given  in  the  definition  of  that  device.  If  a  value  ia  given  for  an  undefined  optional 
parameter,  it  will  be  ignored. 

4.2  Hierarchical  Instantiation  Path  Names 

A  global  instance  name  can  be  defined  by  an  instantiation  path  formed  by  concatenating  local  instance 
names  along  the  path  of  the  instantiation  from  the  root.  Since  local  instance  names  should  be  unique  within 
a  device,  the  result  of  the  concatenation  is  also  globally  unique. 

Local  instance  names  may  be  generated  by  the  system  automatically  or  specified  by  the  user  via  the  II 
optional  parameter.  For  example,  the  execution  of: 

(maks  V-clkinv  2) 

(on  page  7)  constructs  a  tree  of  device  instances  as  shown  in  Figure  2.  These  local  instance  names  are 
generated  by  the  system,  e.g.  dkinv-l  and  clkiav-2. 

5  Signals 

5.1  Basic  Concepts 

Devices  are  connected  via  signals.  A  formal  signal  parameter  of  a  device  can  be  thought  as  a  connection 
point  of  that  device.  When  two  connection  points  share  the  same  signal,  they  are  thought  to  be  connected 
by  a  wire  in  the  circuit. 

There  are  two  types  of  signals: 

1.  Simple  signals  represent  atomic  wires.  For  example,  Vdd  and  GID  are  simple  signals. 

2.  Bundled  signals  (or  cables)  represent  structured  groups  of  wires.  A  cable  is  an  ordered  list  of  signals, 
each  of  which  may  be  a  simple  signal  or  another  cable.  This  recursive  definition  allows  signals  to  be 
structured  hierarchically  thus  forming  a  tree  structure.  The  leaves  of  the  tree  are  simple  signals,  and 
the  internal  nodes  correspond  to  sub-cables. 

A  signal  is  bound  to  a  physical  structure  (or  wire  structure)  and  an  access  structure.  The  wire  structure 
represents  the  actual  group  of  wires  corresponding  to  the  signal,  while  the  access  structure  defines  how  each 
individual  wire  or  sub-cable  is  accessed. 
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Signals  must  be  declared  before  use.  Once  declared,  they  are  used  as  parameters  of  devices.  Every  signal 
appearing  in  a  device  is  declared  either  locally  or  as  a  formal  parameter.  If  the  formal  parameter  is  a  cable, 
then  its  access  structure  must  be  declared  explicitly  unless  the  device  has  no  interest  in  accessing  individual 
wires  in  the  cable.  That  is,  if  the  device  simply  wants  to  pass  the  formal  parameter  to  other  devices  it  is 
not  necessary  to  declare  an  access  structure  for  the  parameter. 

WLreLisp  provides  two  types  of  structured  signals:  homogeneous  structures  (BUS)  similar  to  arrays  in 
PASCAL,  and  the  heterogeneous  structures  (SN)  similar  to  records  in  PASCAL. 

5.2  Access  Mechanisms:  SN  and  BUS 

The  components  of  hierarchical  signals,  i.e.  cables,  are  referenced  via  two  access  mechanisms: 

1.  BUS  structure  whose  components  are  accessed  via  an  integer  index. 

For  example, 

(access  (in  (BUS  1  I))) 

declares  that  the  components  of  in  can  be  accessed  via: 

inCi] .  in[2] .  ...  in[I] 
respectively.  The  index  may  also  go  from  high  to  low. 

2.  Structured  Net  (SN)  whose  components  are  accessed  explicitly  by  name. 

For  example, 

(access  (load  (SI  I  L))l 

declares  that  the  components  of  load  can  be  accessed  via: 

load. H,  load.L 
respectively. 

The  complete  definition  of  the  access  mechanisms,  in  the  form  of  the  extended  BNF,  is  given  in  the 
appendix  B.  Both  BUS  structures  and  SN  structures  can  be  nested.  That  is,  the  component  of  a  BUS 
structure  can  be  another  BUS  structure  or  an  SN  structure,  and  the  component  of  an  SN  structure  can  be 
another  SN  structure  or  a  BUS  structure. 

Each  access  declaration  effectively  constructs  a  tree  of  names  through  which  the  individual  wires  are 
accessed.  For  example,  the  access  declaration  corresponding  to  the  tree  in  Figure  3  is: 

(access  (sysBus  (SI  (ctrl  (SI  RU  STROBE  1CK))  (addr  (BUS  0  23))  (data  (BUS  1  32))))) 

This  can  be  more  easily  represented  in  drawing.  See  Drawing  WireLisp. 

The  fundamental  difference  between  an  SN  and  a  BUS  structure  is  that  the  access  names  in  a  BUS 
structure  may  contain  vanable  indices  which  ate  evaluated  at  run-time,  while  all  access  names  in  an  SN 
structure  are  evaluated  before  execution  starts. 

5.3  Signal  Declarations:  local,  slocal,  shadow,  global,  access 

The  wire  structure  of  a  signal  represents  the  physical  wires  that  connect  devices.  Once  created,  the  signal 
physical  structure  never  changes.  The  basic  mechanism  for  creating  signals  is  the  local  declaration. 

5.3.1  Local  Declarations 
A  local  declaration  does  three  things: 

1.  It  creates  the  named  signal. 

2.  It  creates  the  signal  access  structure  which  is  used  in  the  current  device; 

3.  It  creates  the  signal  wire  structure. 
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sysBus 


sysBus .Ctrl 


sysBus . addr 


sysBus .data 
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«y«Bui.<Ut»  [2] 


sy*8u«.ctrl.RM 

jyaSua .Ctrl .STROBE 


ayaBua. addr  toy  sytBas.addr [23] 

_ _  ....in  ayaBua.data |l]  ayaBua.data [32] 

ayaBua.ctrl.ACK  ayaBua.addr [1] 


Figure  3:  the  access  tree  sysBus 


For  example, 

(local  (phi  (BUS  1  2  (SI  1  L))}) 
creates  the  signal  phi  and  the  4-phase  clock  comprised  of  4  atomic  wires: 

phiCl] • H,  phi Cl] .  L,  phi[2].H,  phi[2].L  (Figure  4  (a)). 

They  can  be  accessed  via  the  structure  (BUS  1  2  (S*  III)  (Figure  4  (b)).  For  example,  the  name  phi[l] 
accesses  the  sub-structure  (phiCl]. H  phiCl]. L). 

The  general  form  of  a  local  declaration  is: 

(local  (namel  nameg  ...  nameK  access-structure-spec)  ...) 

Each  component,  (name!  nameg  ...  nameK  access-sirvciure-spec),  creates  a  list  of  named  signals  that  have 
the  3ame  structure.  If  access-structure-spec  is  missing,  simple  signals  are  created  instead.  In  this  case,  the 
pair  of  enclosing  parentheses  is  also  eliminated. 

Local  signals  in  different  instances  of  a  device  are  differentiated  by  prepending  a  unique  device  instanti¬ 
ation  path  (discussed  in  Section  5.2)  to  their  locally  declared  names  (or  local  names).  Thus  every  signal  is 
uniquely  identified  by  a  path  which  locates  the  device  instance. 

However,  device  path  names  can  be  very  long  if  the  device  hierarchy  is  deeply  nested.  This  may  cause 
storage  problems  for  very  large  circuits.  The  user  may  get  round  this  problem  by  using  short-named  signals 
(or  short  signals).  They  are  declared  similarly  using  the  reserved  word  siocal  instead  of  local.  Short  signals 
are  named  by  prepending  their  local  names  with  a  name  which  is  formed  by  appending  a  unique  integer  to 
the  device  name.  For  example,  suppose  in  a  device  named  loo,  we  declare  that: 

(siocal  (phi  (BUS  1  2  (SI  B  L)))) 

and  the  appending  integer  happens  to  be  5  when  this  declaration  is  evaluated.  Then  in  the  output,  the  four 
wires  of  phi  will  be  identified  as: 

ioo-5/phiCl]  H,  loo-5/phiCl] .L,  foo-6/phi[2] .H,  loo-5/phi[2] ,L 
Since  the  user  probably  does  not  want  to  observe  all  signals,  he/she  may  declare  those  non-interesting  signals 
as  short  signals. 

By  default,  the  unique  integer  series  starts  at  1.  But  the  user  may  specify  a  different  seed  before  executing 
the  program  via: 

(sat  seed  num)  ;  the  series  starts  at  n«m. 

Whenever  a  device  containing  siocal  declarations  is  instantiated,  the  seed  is  incremented  by  1. 

Short  signals  makes  debugging  difficult  because  they  can  be  impossible  to  locate.  The  user  may  turn  off 
all  short  signal  declarations  by: 

(set  SHORT  ‘oil) 


II 


(a)  the  wire  structure  of  the  signal  'phi' 


phi 


phi [1] .H  phi [ 1 ] . L  phi [2] .H  phi [2 ] . L 

(b)  the  access  tree  of  the  3ignal  'phi' 


Figure  4:  the  t oire  structure  and  access  structure  of  phi 


which  causes  WireLisp  to  treat  all  slocal  declarations  as  local  declarations.  By  default,  the  flag  SHORT  is 

on. 

All  signals  must  be  defined  before  use.  Moreover,  this  definition  must  be  complete.  In  some  cases, 
however,  a  device  may  not  understand  the  structure  of  the  wire  connecting  two  of  its  constituent  devices. 
Fortunately,  the  user  may  get  around  this  problem  via  shadow  declarations: 

(shadow  namel  name 2  ...  nameK) 

A  shadow  declaration  simply  creates  a  list  of  unbound  signals.  These  unbound  signals  have  neither  wire 
structure  nor  access  structure.  These  signals  remain  undefined  until  some  component  device  provides  a 
declaration.  This  is  described  in  the  next  section. 

Signals  can  be  declared  globally  as  well.  Global  signals  are  visible  to  all  devices  from  the  point  of 
declaration.  A  global  declaration  has  the  same  syntax  as  a  local  declaration  except  that  the  reserved  word 
local  is  replaced  by  global. 

WireLisp  provides  two  default  global  signals:  Vdd  and  GVD. 

5.3.2  Access  Declarations 

When  the  user  wants  to  access  the  components  of  a  cable  parameter,  he/she  must  specify  an  access  structure 
for  that  parameter.  The  access  structure  can  be  anything  as  long  as  it  matches  the  wire  structure  of  the 
actual  parameter.  This  matching  is  defined  as: 

Suppose  A  is  the  tree  corresponding  to  an  access  structure,  and  B  is  the  tree  corresponding  to  a  physical 
structure.  A  matches  B  if  and  only  if: 

1.  A  is  a  leaf  (and  therefore,  A ’s  name  is  used  to  access  the  the  wire  structure  rooted  at  3),  or: 

2.  Assume  A  =  ( ai  a2  ...  am)  and  B  =  (b\  62  ...  bn)-  Then,  m  =  n  and  a,  matches  bi,  for  all  i  =  1,  2, 

...  m. 

This  implies  that  the  physical  structure  may  be  deeper  than  the  access  structure.  That  is,  the  user  only 
needs  to  specify  the  access  structure  down  to  the  level  of  interest.  If  the  components  of  a  cable  are  not 
accessed  in  a  device  at  all,  then  there  is  no  need  to  specify  its  access  structure. 

The  above  definition  also  implies  that  a  BUS  access  structure  can  be  used  to  access  a  heterogeneous  cable 
as  long  as  the  number  of  indices  matches  the  size  of  the  cable.  For  example,  suppose  the  wire  structure  ((a 
b)  c)  is  passed  to  the  formal  parameter  foo  which  is  declared  as: 
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(access  (foo  (BUS  1  2))) 

Then, 

foo[l]  —  (a  b) 
foo [2]  —  c 

are  all  legal.  The  structure  matching  is  checked  at  run-time.  If  the  access  structure  does  not  match  the 
physical  structure,  an  error  is  reported  and  the  execution  aborts. 

There  is  a  special  case  in  declaring  BUS  access  structures.  That  is,  the  upper  bound  of  the  BUS  index 
may  be  unbound  (?),  such  as: 

(access  (foo  (BUS  1  ?))) 

When  WireLisp  checks  structure  matching,  the  question  mark  will  be  replaced  by  an  integer  which  forces 
the  access  structure  to  match  the  wire  structure.  For  example,  if  ((a  b)  c)  is  passed  to  foo  above,  ?  would 
be  replaced  by  2.  The  following  is  a  more  complicated  example: 

(-davics-  (fool) 

(local  (X  (SI  (H  L  (BUS  1  8  (SI  H  L)))))) 

(-1-  foo2  X) 

...) 

(-dsvics-  (foo2  Y) 

(access  (Y  (SI  H  L  (BUS  1  ?)))) 

...) 

When  the  access  declaration  in  f oo2  is  evaluated,  according  to  the  recursive  definition  of  matching,  the 
question  mark  will  be  replaced  by  8. 

The  above  discussion  assumes  that  the  actual  parameter  is  bound,  i.e.  declared  via  local  or  slocaL  In 
case  the  actual  parameter  is  unbound,  i.e.  declared  via  shadow,  an  access  declaration  behaves  like  a  local 
declaration.  That  is,  it  not  only  defines  the  signal  access  structure,  but  also  creates  the  signal  wire  structure. 
That  is,  a  shadow  signal  is  actually  bound  by  the  first  access  declaration  it  encounters.  For  example,  suppose 
we  define: 

(-device-  (foo) 

(shadow  X) 

(-1-  fool  Vdd  X) 

(-1-  foo2  X  GID) 

...) 

(-device-  (fool  in  out) 

(access  (cut  (BUS  1  2))) 

(format  t  "i  ”  out)) 

(-device-  (foo2  in  out) 

(access  (in  (BUS  1  2))) 

(format  t  "I  ”  in)) 

The  execution  of 
(sake  foo) 

will  print  the  following  two  lines  on  the  screen: 
out  out 

If  foo  reverses  the  order  of  calling  fool  and  tool,  then  the  output  would  be: 
in  in 

A  subtle  problem  arises  when  an  unbound  actual  parameter  meets  an  unbound  BUS  access  structure  (?). 
Since  there  is  no  way  to  determine  the  value  of  the  question  mark,  WireLisp  has  to  report  the  error  and 
abort  the  execution.  This  implies  that  the  user  must  re-arrange  the  order  of  device  instantiations  should 
this  situation  ever  occur. 

5.4  Signal  Operations 

•  (BUS-raf  stg  index )  or  stg[index]  returns  a  signal  whose  wire  structure  and  access  structure  is  the 
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index'th  component  of  stg. 

•  (SI-ref  stg  field )  or  stg. field  is  similar  to  BUS-rsl  except  access  is  via  the  given  SN  field. 

•  (siz«-oi  stg )  returns  an  integer  which  is  the  number  of  (top-level)  components  in  the  given  wire 
structure.  For  example, 

(local  (X  (BUS  1  8  (SI  H  L)))) 
creates  a  signal  of  size  3.  Be  default,  the  size  of  simple  signals  is  1. 

•  (print  stg  sir)  prints  the  signal  sig  in  the  output  stream  sir.  A  signal  name  is  formed  by  concatenating 
its  unique  path  name  with  its  local  name. 

•  (-connect-  sigl  sigt ...  sigN )  aliases  a  list  of  signals.  That  is,  the  physical  wires  represented  by  these 
signals  are  connected  together.  The  output  format  of  aliasing  is  determined  by  the  user  via  the  special 
function  named  print-connect-sinple-signal.  For  example,  to  produce  .sim  format  output,  the 
user  may  define: 

(define  (print-connsct-siapls- signal  si  s2) 

(»l-print  "■  1  1  %'•  si  s2)) 

Then, 

(-connect-  sigl  sigS ) 
will  show  up  as: 

=  sigl  stgS 

If  the  signals  have  hierarchical  structures,  the  leaves  in  their  structure  trees  are  connected  correspond¬ 
ingly  from  left  to  right.  That  implies  all  of  the  given  wire  structures  must  have  the  same  number  of 
leaves  although  they  may  not  have  the  same  size  (the  value  returned  by  sizs-of). 

There  are  also  a  number  of  ways  of  forming  new  signal  structures  from  the  given  signals: 

•  (-B-  stgl  sig2  ...  stgN):  return  a  new  signal  which  is  the  bundling  of  the  given  signals.  The  size  of 
the  new  signal  is  N. 

•  (-C-  stgl  sig2  ...  stgN):  return  a  new  signal  which  is  the  concatenation  of  the  given  signals.  The  size 
of  the  new  signal  is  the  sum  of  the  given  signals’  sizes. 

•  (-S-  sigl  sig2 ):  return  a  new  signal  which  is  the  top-level  shuffling  of  the  two  given  signals.  The  size 
of  the  new  signal  is  the  sum  of  sizes  of  the  given  signals. 

•  (-R-  sig):  return  a  new  signal  which  is  the  top-level  reversal  of  the  given  signal. 

•  (-FT.-  stg):  return  a  new  signal  which  is  the  bit-by-bit  flattening  of  the  given  signal  from  left  to  right. 

The  size  of  the  new  signal  is  the  same  as  the  number  of  atomic  wires  in  the  given  signal. 

•  (-FR-  sig):  return  a  new  signal  which  is  the  bit-by-bit  flattening  of  the  given  signal  from  nght  to  left. 

The  size  of  the  new  signal  is  the  same  as  the  number  of  atomic  wires  in  the  given  signal. 

All  of  the  above  operations  return  an  anonymous  signal  which  has  no  access  structure. 

5.5  A  Syntactic  Shorthand:  Iterators 

Iterators8  are  used  for  compact  representation  of  a  list  of  names.  An  iterator  is  of  the  form: 
nl  :n2 

where,  nl  and  n2  are  the  maximal  substrings  of  digits  appearing  in  a  string.  For  example,  the  iterator  in 
data0:7  is  0:7;  and  in  d2-l:4  is  1:4.  There  may  be  an  arbitrary  number  of  iterators  in  a  name  string.  For 
example,  the  iterators  in  d2-l:5d2-0:l  are  1:5  and  0  '. 

‘Iterators  were  suggested  many  yean  ago  by  Ivan  Sutherland. 
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The  way  an  iterator^works  is  to  produce  a  list  of  different  names  which  vary  only  in  the  iterator  portion. 
The  default  iterating  step  is  1  if  nl  is  no  larger  than  n2.  Otherwise,  it  is  -1.  For  example,  foo0:5  expands 
to: 

fooO,  fool,  foo2,  foo3 ,  foo4,  looS 

If  a  name  has  more  than  one  iterator,  it  forms  a  nested  loop  with  the  outermost  loop  to  the  left.  For  example, 
inO:  15-0:7  expands  to: 

in0-0,  iaO-1,  ...  inO-7,  inl-0,  inl-1,  ...  ial6-6,  inlS-7 

Furthermore,  the  user  can  even  specify  the  step  of  the  iteration  by  appending  string  step  to  an  iterator, 
where  step  is  a  maximal  substring  of  digits.  For  example,  onto :  7 :  2in  expands  to: 
ontOin,  out2in,  out4in,  outflin 

It  is  important  to  remember  that  iterators  are  simply  syntactic  shorthands.  For  example, 

(local  ini: 4) 

is  equivalent  to  the  declaration: 

(local  ini  in2  in3  in4) 
which  is  different  from: 

(local  (in  (BUS  1  4))) 

Iterators  may  appear  in  BUS  references  as  well,  such  as  foo[l:4].  These  iterators  may  even  contain  variable 
bounds,  such  as  foo[l :■],  where  I  is  computed  at  run-time.  Therefore,  they  are  called  dynamic  iterator*. 
Iterators  not  appearing  in  BUS  references  are  called  static  iterators  because  they  are  expanded  into  a  list  of 
names  (without  parentheses)  before  the  program  execution. 

Dynamic  iterators  are  expanded  into  a  list  of  names  at  run-time.  For  example, 
in  Cl:  I] 

with  ■  *  4  is  equivalent  to  a  list  of  4  signals: 
inCl]  in[2]  inC3]  in[4] 

So  the  user  may  use  dynamic  iterators  in  the  same  way  as  using  static  iterators.  For  example, 

(-B-  in[l:I:2]  in[2:I:2]) 

returns  a  signal  resulting  from  shuffling  the  wire  structure  of  in  so  that  all  odd  components  come  before  all 
even  components. 

5.0  Signal  Structure  Types 

Unlike  typing  in  conventional  languages,  signal  structure  typing  in  WireLisp  is  more  of  a  syntactic  short¬ 
hand.  The  binding  of  structures  to  names  via: 

(s-type  s-name  access-structure-spec) 

simply  implies  that  any  reference  to  j-name  will  be  replaced  statically  by  the  structure  it  is  bound  to.  So 
signal  types  must  be  defined  before  they  are  referenced. 

s-type  declarations  are  global,  i.e.  the  declaration  becomes  effective  from  the  point  of  its  evaluation. 
If  two  structure  types  happen  to  have  the  same  name,  the  new  binding  will  overwrite  the  old  one  and  a 
warning  is  issued.  Normally,  the  user  collects  all  common  structure  definitions  in  a  file  which  is  loaded 
before  executing  the  program.  For  example,  a  file  named  types. wl  might  contain: 

(s-typs  pair  (SI  H  L)) 

(s-typs  clock  (BUS  1  2  pair)) 


6  Foreign  Devices 

WireLisp  is  used  to  specify  the  structure  of  a  circuit.  However,  there  are  cases  where  this  is  not  a  good 
representation.  For  example,  programmable  logic  arrays  (PLA)  are  best  described  by  a  truth  table  ,  and 
FSM’s  by  a  state  diagram. 

A  device  is  termed  foreign  if  it  is  defined  by  some  means  other  than  WireLisp  drawings  or  procedures. 
Foreign  devices  enable  the  user  to  integrate  virtually  any  design  representation  into  WireLisp.  However, 
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there  must  be  a  transformer  which  converts  the  external  representation  into  a  WireLisp  procedure.  For  ex¬ 
ample,  if  the  user  specifies  a  PLA  via  a  truth  table,  then  there  must  be  a  program,  say  pla2wl,  that  compiles 
truth  tables  into  WireLisp  implementations.  Since  WireLisp  has  no  idea  what  the  external  representation 
is  and  therefore  which  transformer  should  be  used,  the  user  must  explicitly  specify  the  conversion  via  the 
Unix  make  facility.  For  example,  suppose  the  foreign  device  foo  is  defined  via  the  truth  table  contained  in 
the  file  foo.pla,  then  the  Unix  makefile  must  include: 

foo.sxt:  foo.pla 

pla2sl  foo.pla  foo.sxt 

Then  the  execution  of  the  Unix  command 

sake  foo.sxt 

will  create  the  WireLisp  procedure  for  the  device  foo  which  is  saved  in  foo.ext. 

A  foreign  device  is  instantiated  by  executing  the  corresponding  device  procedure.  A  foreign  device  is 
instantiated  by  -FI-  in  the  form: 

(-FI-  dev-name  signal  signal j  ...  signal 

(prop  (opt-param-namei  value i)  ...  ( opt-param-name *  valucj))) 

Since  it  is  critical  to  maintain  the  right  parameter  order,  WireLisp  requires  the  user  to  make  a  drawing  for 
each  foreign  device.  This  drawing  simply  defines  the  device  header  (or  device  interface)  and  declares  access 
structures  for  the  signal  parameters,  if  necessary.  The  external  representation  must  use  the  names  as  defined 
in  the  drawing.  When  a  foreign  device  is  loaded,  WireLisp  does  three  things: 

1 .  Runs  the  drawing  through  dp2wl  with  -g  flag.  This  creates  the  corresponding .  wl  file  with  the  following 
expression  automatically  inserted  at  the  end  of  the  procedure: 

(include  device-name. ext) 

WireLisp  include  is  very  similar  to  C  #  include  (see  Section  10  2) 

2.  Executes  the  Unix  command  make  to  create  the  .ext  file  which  actually  defines  the  device.  In  particular, 
WireLisp  requires  this  file  to  be  a  single  block  expression. 

3.  Loads  the  .wl  file  of  the  device.  At  this  point,  the  include  expression  is  substituted  by  the  contents 
of  the  given  .ext  file. 

Foreign  devices  may  be  instantiated  with  general  parameters  as  well: 

(-FI-  dev-name  signal !  ...  signalm  gen-param\  ...  gcn-paramn 

(gen  {gen~param-name\  value t)  ...  (gen-param-name^  valuej))) 

(prop  (opt-param-namei  value j)  ...  ( opt-param-namck  value,))) 

For  different  sets  of  general  parameter  values,  there  will  be  different  pairs  of  .wl  and  .ext  files  generated, 
each  defining  an  implementation  according  to  the  specific  values.  For  example,  suppose  the  foreign  device 
foo  has  two  general  parameters:  V  and  D.  When  foo  is  instantiated  with  W=2  and  0*1,  WireLisp  performs 
the  following  steps  to  create  the  device  foo_2_l: 

1.  Runs  the  drawing  through  dp2wl  with  -g  * '  _2 -1*  *  flag.  It  creates  the  file  foo.2JL.wl  which  defines 
the  procedure  foo_2_l  with  the  following  expression  automatically  inserted  at  the  end  of  the  procedure: 

(includs  *  'f oo22.1 .  sxt  ’  ’ ) 

2.  Executes  the  Unix  command: 

aak*  W*2  D=1  foo_2,l.sxt 
The  makefile  must  have  an  entry  such  as: 

fooJSVJSD.  sxt:  foo.pla 

pla2vl  -«  $W  -d  $0  foo.pla  fooJ$V_$D.sxt 
Note  that  the  macro  names,  such  as  V  and  0  here,  must  be  upper-case. 

3.  Loads  foo.2 _l.wl. 
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WireLisp  baa  no  control  over  what  may  be  specified  in  the  Unix  makefile.  This  gives  the  user  a  chance 
to  specify  other  related  activities,  such  as  creating  C  routines  for  COSMOS  simulation.  In  fact,  the  user  may 
not  create  the  .ext  file  at  all.  In  that  case,  the  includs  expression  is  simply  ignored.  That  is,  the  drawing 
alone  defines  the  device. 

WireLisp  assumes  that  the  root  device  can  never  be  a  foreign  device. 


7  Automatic  Loading:  make  and  load-file 

A  WireLisp  program  is  executed  by  invoking  ukt  on  the  root  device,  e.g. 

(aake  clkinr) 

WireLisp  sikt  automatically  loads  the  definition  of  a  device  when  it  is  first  instantiated.  Similar  to  Unix 
make,  WireLisp  does  not  load  a  device  if  it  has  been  loaded  and  its  definition  is  still  up-to-date. 

If  a  device  is  instantiated  by  -I-,  WireLisp  assumes  that  it  is  defined  either: 

•  By  a  drawing  in  a  .dp  file  named  after  the  device,  or: 

•  By  a  procedure,  in  the  . wl  file  named  after  the  device. 

If  the  .dp  file  exists,  and  is  newer  than  the  corresponding  .wl  WireLisp  automatically  invokes  the  schematic 
extractor  dp2wl  to  convert  the  drawing  into  the  corresponding  .wl  file.  WireLisp  then  loads  the  .wl  file  of 
the  device  before  executing  the  device  procedure. 

If  a  device  is  instantiated  by  -FI-,  WireLisp  uses  the  make  facility  to  create  the  device  file  as  described 
in  the  previous  section. 

Automatic  loading  ensures  that  every  device  is  up-to-date  and  that  no  redundant  work  is  performed. 
This  implies  that: 

•  A  device  is  loaded  only  if  the  .dp  or  .wl  files  have  changed  since  the  device  was  last  loaded. 

•  dp2wl  is  involved  only  if  the  .dp  file  is  newer  than  the  .wl  file  (or  if  the  .wl  file  does  not  exist). 

When  maks  is  invoked  on  a  device  with  signal  parameters,  WireLisp  creates  the  right  number  of  unbound 
signals  and  passes  them  to  the  root  device.  These  signals  must  be  declared  by  access  declarations  which  act 
as  local  declarations.  For  example,  consider: 

(-device-  (.too  a  b) 

(access  a  (b  (BUS  12))) 

(format  T  "simpls  signal:  i  ;  cable  component:  I"  a  b[l))) 

The  execution  of 
(make  foo) 

will  print  on  the  screen: 

simple  signal:  k  ;  cable  component:  B[l] 

WireLisp  fills  in  only  the  missing  signal  parameters.  If  the  root  device  has  general  parameters,  the  user  must 
provide  their  values  in  the  right  order  when  executing  maks. 

The  user  can  manually  load  a  device  as  well: 

(load-file  device-name ) 

For  example,  (load-file  ’too) 

The  named  device  is  loaded  just  like  in  make,  but  it  is  not  instantiated. 


8  Incremental  Execution:  resume 

When  an  error  occurs  during  execution,  it  is  always  safe  to  start  all  over  again  after  fixing  the  bugs.  However, 
some  errors  are  continuable,  i.e.  the  result  so  far  is  correct  and  the  execution  may  resume  after  fixing  the 
bugs.  In  these  cases,  it  would  be  a  great  waste  to  start  all  over  again,  especially  for  very  large  programs. 
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In  particular,  WireLisp  syntax  errors  are  detected  when  a  device  is  loaded.  Since  WireLisp  implements 
dynamic  loading,  a  syntax  error  may  be  detected  long  after  execution  starts.  However,  almost  all  syntax 
errors  are  continuable.  Therefore,  WireLisp  provides  a  simple  resume  function  —  after  fixing  the  syntax 
errors,  the  user  may  continue  the  execution  by  typing: 

(resua«) 

Executing  (resume)  is  equivalent  to  repeating  the  last  load  and  then  instantiating  the  device  just  loaded. 
This  facility  is  aimed  only  ai  syntax  error  recovery.  The  user  must  make  sure  that  the  error  is  indeed 
continuable. 

9  Output 

There  are  two  questions:  What  is  in  the  output?  Where  is  the  output  saved? 

What  is  produced  in  the  output  depends  on  the  user.  Instantiating  a  device  simply  executes  the  corre¬ 
sponding  device  procedure.  The  user  may  insert  whatever  output  statements  are  necessary  in  the  procedure. 
For  example,  if  we  want  to  create  .sim  format  output,  we  may  define  ptrans  and  strans  such  that  each 
prints  a  line  describing  itself:  its  name,  connecting  signals,  and  the  width  and  length  (see  Appendix  A). 
Instantiating  a  device  would  cause  a  cascade  of  instantiations  of  lower-level  devices  until  the  primitives 
(ptrans  and  strans)  are  encountered.  The  side-effect  of  instantiating  the  root  device  is  to  produce  a  list  of 
transistor  descriptions  corresponding  to  the  root  device  instance. 

By  default,  WireLisp  uses  the  CMOS  library  which  produces  .sim  format  output  which  is  saved  in  the 
.sim  file  named  after  the  root  device.  In  general,  the  user  may  choose  different  libraries  and  file  extensions 
as  described  in  the  next  section. 

The  .sim  format  output  requires  the  following  line  to  be  at  the  beginning  of  the  file: 

I  units:  units  tech:  technology-name  format:  format-name 
The  three  parameters,  amts,  technology-name  and  format-name,  may  be  set  (before  the  program  execution) 

via: 

(set-units  number) 

(set-tech  name) 

(set-format  name) 

For  the  CMOS  technology  used  here,  their  default  values  are: 
units:  100  (centimicrona) 
tech:  cmos-s 
format:  UCB 


10  Device  Library 

A  device  library  is  a  set  of  devices  for  a  particular  implementation  technology  and  output  representation. 
By  default,  WireLisp  adopts  the  CMOS  technology  producing  the  .sim  format  output.  This  is  chosen  when 
WireLisp  is  invoked  by: 

(eirelisp)  or.  (wirelisp  'caoslib  ’sia) 

However,  the  user  may  choose  a  different  library  and/or  a  different  output  file  extension  by: 

(wirelisp  library-name  file-ext) 

This  indicates  that  WireLisp  should  load  the  named  device  library  (saved  in  /iftrory-name.wl)  and  adopt 
the  given  file  extension.  If  file-ext  is  missing,  .sim  is  assumed  as  the  extension.  In  the  library  file,  the  user 
needs  to  tell  WireLisp  which  devices  are  defined  in  the  library  Appendix  A  gives  a  simplified  example. 

In  general,  the  following  operations  help  the  user  to  set  up  the  library: 

•  (add-lib  sequence-of-devtce-names):  add  the  given  devices  to  the  library  device  list. 

•  (dsl-lib  sequence-of-devtce-names):  delete  the  given  devices  from  the  library  device  list. 
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Figure  5:  logic  gates  computing  GT,  EQ,  and  LT 
•  (print-lib):  print  out  the  current  library  device  list. 

In  the  default  CMOS  library,  the  length  and  width  of  ptrans  and  etrana  are  optional  parameters  with 
default  values  of  2  and  3.  But  in  a  particular  design,  the  user  may  want  different  default  values  for  the 
length  and  width.  In  that  case,  instead  of  repeatedly  specifying  the  width  and  length  for  each  transistor 
instantiation,  the  user  may  set  them  globally  by: 

(sst-ptrans  length  width) 

(sst-strans  length  width) 

These  new  values  will  become  the  defaults. 

The  operations  sst-ptrans  and  sst-strans  must  be  evaluated  before  program  execution. 


11  Examples  of  WireLisp  Extensions 

WireLisp  is  an  open  system.  Just  like  any  Lisp  system,  it  is  easy  to  add  new  features.  Here  are  a  few 
examples. 

11.1  Equations 

While  much  of  the  description  of  a  digital  system  is  structural,  there  are  parts  of  the  system  which  have  no 
obvious  structure,  but  whose  input-output  behavior  is  well-understood.  As  our  initial  attempt  to  incorporate 
behavioral  description  in  WireLisp,  logic  expressions  are  provided  for  the  inclusion  of  simple  logic  equations 
as  replacements  for  small  collections  of  logic  gates.  For  example,  the  logic  gates  computing  GT,  EQ,  and  LT 
in  Figure  5  could  be  replaced  by  the  following  three  expressions: 

(logic  GT  (or  GT2  (and  EQ2  GT1))) 

(logic  EQ  (and  BQ1  EQ2)) 

(logic  LT  (and  (not  EQ)  (not  GT))) 

Each  logic  expression  is  equivalent  to  defining  a  device  whose  behavior  is  described  by  the  equation  and 
instantiating  that  device  in  the  context  of  the  logic  expression.  A  set  of  Lisp  functions  have  been  written  for 
translating  logic  expressions  directly  into  the  equivalent  WireLisp  device  procedures. 

11.2  include 

WireLisp  include  expressions  are  similar  to  C  # include  directives: 

(includs  file-name) 
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The  express^  is  replaced  by  the  contents  of  the  given  file.  If  the  file  does  not  exist,  this  express.on  is  simply 


11.3  Functions  for  COSMOS  Simulations 

There  have  been  a  number  of  functions  added  for  COSMOS  simulations. 

1.  (cos-func  dev-name  inst-name  ( input-signals )  ( zero-delay-signals )  {output-signals)) 

This  function  prints  out  one  line  in  the  output  file,  which  looks  like: 

B  eztended-mst-name  dev-name  input-signals  ;  zero-delay-signals  ;  output- signals 

Here,  ertended- inst-name,  which  is  the  concatenation  of  the  invoking  device  instance  name  and  the 
given  inst-name,  indicates  the  path  of  this  particular  instantiation,  devnamc  gives  the  name  of  the 
functional  block  called.  Signals  within  a  group  are  separated  by  blanks.  Simple  signals  are  printed  as 

Lire  “ j. and  Cab  e®  are  ?attened  Wlth  the  wire  structure  leaves  enumerated  from  right  to  left  because 
BUS  indices  are  assumed  to  range  from  least  to  most  significant  bits. 

2.  (inputs  input-signals) 

This  function  prints  out  one  line  for  each  given  signal: 

A  signal  Sia:In 

If  the  input  signal  is  a  cable,  it  is  flattened  with  the  wire  structure  leaves  enumerated  from  left  to  right. 
One  leaf  occupies  one  line.  * 


3.  (outputs  output-signals) 

This  function  prints  out  one  line  for  each  given  signal: 

A  signal  Sia:Out 

Cables  are  treated  in  the  same  way  as  in  inputs. 

4.  (vectors  cable- signals) 

This  function  prints  out  one  line  for  each  given  cable: 
v  cable-name  sequence-of-cable-components 

Here,  cable  components  refer  to  the  leaves  of  the  cable  wire  structure  which  are  enumerated  from  right 
to  left.  Simple  signals  cannot  appear  in  a  vector  expression. 
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A  An  Example  of  Device  Library 

;;;  define  hoe  to  print  aliasing  signals. 

(define  (print-connect-simple-signal  si  s2)  ; produce  .  sia  output 
(el-print  "=  A  A  r/,’ '  si  s2)) 

;;;  define  shat  is  in  the  library. 

(add-lib  etrans  ptrans) 

(-device-  («trans  gate  source  drain  (L  2)  (M  3))  ;optional  length  ft  eidth 
(el-print  "e  i  i  1  S”  gate  source  drain  L  W) ) 

(-device-  (ptrans  gate  source  drain  (L  2)  (V  3)) 

(el-print  "p  i  i  2  9,”  gate  source  drain  L  W) ) 


B  Signal  Access  Structure  Syntax 

Note  that:  (1)  Curly  brackets  represent  the  iteration  of  one  or  more  times.  (2)  Any  name  which  is  legal  in 
T  is  also  legal  in  WireLisp.  (3)  null  mean a  nothing  should  be  there. 

( local-signal-decl )::  (local  {{field)}) 

( access-dec l)::  (access  {(field)}) 

(field)::  (name)|  ({(name)}  (struct- spec)) 

( struct-spec )::  (SN-spec) \  (BUS-spec) |  null 

{ SN-spec )::  (SN  {(/ieM)}) 

(BUS-spec)::  (BUS  (low)  (high)  ( struct-spec )) 

where,  both  low  and  high  can  be  any  integer  expression.  The  index  advance  step  is  1  or  -1,  depending  on  if 
low  is  smaller  or  larger  than  high. 
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